IRIX Development Foundation for IRIX 6.4

home *** CD-ROM | disk | FTP | other *** search

/ IRIX Development Foundation for IRIX 6.4 / SGI IRIX 6.4 Development Foundation.iso / docs6.4 / relnotes / compiler_dev / ch4.z / ch4

Wrap

Text File | 1997-09-11 | 20KB | 528 lines

- 1 - Base Development 7.2 Release Notes - 2 - DDDDooooccccuuuummmmeeeennnntttt NNNNuuuummmmbbbbeeeerrrr 000000008888----1111777788882222----000033330000 4. _K_n_o_w_n__P_r_o_b_l_e_m_s__a_n_d__W_o_r_k_a_r_o_u_n_d_s 4.0.1 _M_I_P_S_p_r_o__C_o_m_p_i_l_e_r_s +o The MIPSpro C compiler requires adherence to the ANSI C requirement (3.3.2.2) which states that calls to varargs routines must have a prototype visible at the call and the function definition (if they pass floating point actual arguments), and must use the _s_t_d_a_r_g._h (ANSI C section 4.8) interface. The compiler will issue a warning if it sees floating point parameters passed to _p_r_i_n_t_f, _s_p_r_i_n_t_f, or _f_p_r_i_n_t_f without a prototype. _l_d will issue a warning if possible when floating point parameters are passed to varargs routines without prototypes visible at the call site. However, _l_d cannot issue such warnings if the call is via a function pointer to an anonymous function. SGI-provided library functions like _p_r_i_n_t_f all use prototype-style declarations in the system header files (i.e. <stdio.h>), so simply including the relevant header files in files which call them satisfies this requirement. User-written code should use the same practice. +o The 64-bit subprogram call interface passes all parameters in 64-bit containers. The first eight are passed in registers, sign- extending integers smaller than 64 bits to 64-bits. Beyond the first eight, parameters smaller than 64-bits (except structs) are passed right justified in the 64-bit container in memory. Therefore, passing an int (32-bit) parameter and referencing it in the callee as a long or pointer (64-bit) may pick up extraneous garbage in the high-order half of the value. Use of prototypes will solve this problem by automatically converting the passed value; otherwise, the normal C rules for correspondence between actual and formal parameters must be followed. An important potential cause of - 3 - this problem is defining "_N_U_L_L" as "0" and then passing it as an unprototyped pointer parameter. To avoid this, define "_N_U_L_L" as "0L" or "(void *)0". +o There are a number of similar issues which arise in porting C code to the 64-bit programming model. See the _M_I_P_S_p_r_o _6_4-_b_i_t _P_o_r_t_i_n_g _a_n_d _T_r_a_n_s_i_t_i_o_n _G_u_i_d_e for more information. +o The software pipelining statistics that are generated when compilations are performed with the -_O_3 -_S -_r_5_0_0_0 flags are overly conservative in calculating peak performance of the R5000. As a result, software pipelining reports such as the one below can indicate values over 100% of peak performance for this processor. For example: #<swps> 100 estimated iterations before pipelining #<swps> Not unrolled before pipelining #<swps> 32 cycles per iteration #<swps> 64 flops (196% of peak) (madds count as 2) #<swps> 32 flops (100% of peak) (madds count as 1) #<swps> 32 madds (193% of peak) #<swps> 32 fmuls (193% of peak) (madds count as 1) #<swps> 32 fadds (100% of peak) (madds count as 1) #<swps> 16 mem refs ( 50% of peak) #<swps> 31 integer ops ( 96% of peak) (mem refs included) #<swps> 63 instructions ( 98% of peak) #<swps> 2 short trip threshold #<swps> 21 ireg registers used. #<swps> 24 fgr registers used. +o A new flag has been provided for the -_O_P_T: ... group. -_O_P_T:_w_r_a_p__a_r_o_u_n_d__u_n_s_a_f_e__o_p_t=_O_F_F will disable both the induction variable replacement and linear function test replacement optimizations. These optimizations are normally enabled at general optimization level -_O_3. The optimizations are unsafe in that they may potentially generate incorrect code for situations that may arise (but are not limited to) when there are multiple induction variables in loops and their combined initial values can overflow or wrap around. General use of this flag is discouraged because it can degrade performance. It is provided, however, as a diagnostic tool to identify the situation - 4 - described above. +o The assembly language file created by -_n_3_2 -_m_i_p_s_4 -_i_p_a -_k_e_e_p is under certain circumstances incompatible with the assembler. 4.0.2 _l_d +o The ld option -default_delay_load can occasionally cause problems. In certain cases, when an application (MAIN) references a dso (libONE.so) which contains a function which references a global variable (FOO) defined in another dso (libTWO.so) which has been built with -default_delay_load, the application may show the following error: 1374:MAIN :rld: Fatal Error: unresolvable symbol in libONE.so: FOO In such cases, ld is supposed to override the delay_load marking for libTWO.so and mark it as immediate load. However, sometimes it fails to do this. The workaround is build libTWO.so without using -default_delay_load. (Bug #494294) +o ld options -delay_load and -default_delay_load can slow down run-time performance of certain applications. This is because rld will try to re-resolve undefined symbols in the main executable and all currently loaded dsos. (Bug #506076) +o Some programs linked with libpthread.so may be slow to quickstart. (and therefor with anything after it on the liblist). In some cases libpthread.so was not created linked with the applicable most up-to-date libc.so.1 so the libc/libpthread conflict list is not complete. In such cases rqsall/rqs will refuse to requickstart libpthread.so. (Bug #507098) +o Sometimes rld gets DSO visibility wrong and calls to dlopen will result in an error saying dlopen can't resolve a symbol defined - 5 - in one DSO (FOO) and then referenced in DSO (BAR). This occurs when parts of DSO FOO are marked as hidden with respect to some DSO's, even if a particular symbol in FOO should be visible to BAR. The workaround in to re- order the loading of DSO's so that FOO is loaded after BAR. (Bug #455035) +o ld sometimes complains when -_u_p_d_a_t_e__r_e_g_i_s_t_r_y or -_e_x_p_o_r_t_s are used on the link line (Bug #375616). The error messages that are being generated in certain cases when these flags are used are: ld: ERROR 4: Conflicting flag setting: --update_registry ld: ERROR 4: Conflicting flag setting: -exports 4.1 _d_b_x +o _d_b_x cannot correctly display data values of C++ class members that have a C++ class offset (offset in bytes from the beginning of the class) greater than 32767. This bug does not apply to C structures or unions or Fortran records: it applies only to C++ classes. The symptom is that the data values displayed (for data that has a class offset greater than 32767 bytes) are incorrect. +o _l_d(1) options like -Bsymbolic and -hides and -hidden_symbol cause ELF markings to be made to cause _r_l_d(1) to resolve symbol references differently than by default. These markings are not noticed by _d_b_x. _d_b_x always resolves externals starting with the present dso (the current frame and scope) working outwards to the external scope of that dso/a.out and then proceeds sequentially thru the DSOs to find the external. _d_b_x can therefore print an incorrect value given an external name when there are multiple externals with the same name and the resolution rule _d_b_x follows at present does not match the rules rld uses. Use the wwwwhhhhiiiicccchhhh command to see what symbol an external name resolves to. Use specific _d_b_x naming using the dso module name to resolve a name to a specific dso. For example, to print a value errno from libc.so.1 (bypassing - 6 - the incomplete lookup rules), use the _d_b_x command print libc.errno. +o If _RLD_ROOT is set to pick up a different _l_i_b_c._s_o._1, and breakpoints are set in _l_i_b_c._s_o._1 before running the program, the breakpoints become permanent, that is they cannot be deleted. A workaround is to stop in main before setting any breakpoints in libc.so.1. +o In single-user state, if _d_b_x core dumps on startup, try the command sequence /etc/init.d/network start /etc/init.d/network stop _T_h_e_n _r_e_t_r_y _d_b_x. Usually the message before the abort will start with EEEERRRRRRRROOOORRRR:::: bbbbiiiinnnndddd ffffaaaaiiiilllleeeedddd eeeerrrrrrrrnnnnoooo 111122226666. +o If a store instruction updates a location which is being tracked with a stop/when/trace and the cpu is an R8000 and the store instruction is in any delay slot (jump or load) and the program is a 32-bit program, the stop/when/trace may not be triggered and if it is triggered may print out/use an incorrect value. +o On an R8000: if an interactive function call calls a function which has anything but a no-op (aka 'nada') in the delay slot of a return from that function (jr ra) _d_b_x will print <Unimplemented> and cannot print the function's return value. The function has been executed and any side effects happened. Clear the incomplete 'return' with the cccclllleeeeaaaarrrrccccaaaallllllllssss command or the rrrreeeettttuuuurrrrnnnn command. +o It is difficult to set a breakpoint in some relatively new kinds of C++ functions (for example X::operator int and X::operator new[]) The only ways are to determine the full demangled name and enclose it in back- quotes or to determine the full mangled name and use that. Long accepted forms, such as X::operator + can be named to dbx as X::+. - 7 - +o If you move a corefile and its a.out to another machine, _d_b_x will probably warn about mismatches with certain DSOs when you try to use _d_b_x on the a.out and corefile. You cannot safely copy the DSOs from the other machine into the corresponding locations of the new machine (i.e., /usr/lib) and if you copy them somewhere else (for example if you copy them into the same directory as the core file and a.out) there is no way to tell _d_b_x where to find them (_d_b_x does not understand that the information in the corefile about the dso absolute paths should be disregarded). +o If the list of DSOs (and their respective library list as shown by eeeellllffffdddduuuummmmpppp ----DDDDllll) has a circularity _d_b_x will keep reading the circular set over and over forever, never finishing. Such a circularity is improper and ill-advised and should be removed by changing your DSO build (the circularity will be in your DSOs). While _d_b_x ought to catch and warn about this, it does not in this release (except for some simple circularities where a dso names itself: it does catch some very simple cases but does not issue a warning). +o If you set two watchpoints at the same address, _d_b_x will correctly output an error message when you try and set the second watchpoint. However, if you delete the first watchpoint, the second watchpoint will appear even though it does not show up in any status. 4.1.1 _L_i_b_r_a_r_i_e_s These are known problems in compiler-associated libraries: +o In general, routines in the ----llllmmmm44443333 library might not conform to either SVR4 or IEEE with respect to diagnostics or return values. These discrepancies are, however, described in the manual pages of the constituent functions. (See Section 3.5 for math library changes). The following particular problems are known (these problems exist in ----llllmmmm44443333 routines, but not in ----llllmmmm routines): - 8 - - The ----llllmmmm44443333 _y_0, _y_1, and _y_n functions produce underflow inconsistently (with respect to ----llllmmmm). +o The results from _v_s_i_n, _v_c_o_s and _v_t_a_n are valid only for argument values between (pi*2e19) and (pi*2e-19). +o The results from _v_s_i_n_f, _v_c_o_s_f and _v_t_a_n_f are valid only for argument values between 2e28 and 2e-28. +o The results from _v_s_q_r_t_f and _v_s_q_r_t are not always correctly rounded. +o The mips4 versions of the following routines do not support denormal arguments: _v_l_o_g_f, _v_l_o_g_1_0_f, _v_l_o_g_1_0, _v_l_o_g. All return NaN under those circumstances. +o Because the multiply-add instructions are rounded twice on the R10000, the Fortran intrinsics _A_M_O_D and _D_M_O_D are less accurate than than they are on earlier chips.